1. Field of the Present Invention
The present invention generally relates to the field of computer networks and more particularly to a network computer boot method and software that is transparent to the specific type of boot device such that the same code is used whether booting from a Network File System (NFS) server, a hard disk, or a (Trivial File Transfer Protocol) TFTP server.
2. History of Related Art
The importance of maximizing value by carefully controlling the implementation of resources on each computer within a computer has network has increased with the increasing number of applications for which a local area network provides a desirable solution. Many existing local area networks consist largely of two or more interconnected desktop computers, possibly in combination with a large capacity, centralized server machine. The wide spread availability and acceptance of disk based operating system software that eliminated much of the design overhead associated with implementing local area networks has greatly contributed to the proliferation of networks comprised of a two or more essentially stand alone machines.
Despite the ease with which they can be implemented, these networks are not designed to maximize value to the end user because they fail to distribute resources in an optimal fashion. More specifically, networks comprised of a collection of stand alone machines unnecessarily duplicate resources that can be offered via the network and centralized in one or more network servers. Attempts to address this concern include centralizing mass storage in a network server, RAID system, or other suitable storage facility.
Unfortunately, the removal of hard disks from network computers in an effort to reduce network costs introduces other problems. One such problem is the manner in which each of the diskless network computers is booted. In a desktop-type machine, the entire operating system resides in the machine""s local permanent storage, where it is easily transferred into system memory as needed. In a diskless network computer, it is typically necessary to retrieve all or part of the operating system from a remote, permanent storage device. Typically, a diskless network computer includes a small amount of local permanent storage (such as a ROM or other suitable non-volatile memory device) that has sufficient capacity to include high level boot code that is responsible for transferring the operating system from a remote location and restoring the network computer to a known state.
Computer networks are frequently characterized by a variety of different computing devices. In such an environment, network computers make take on many variations. While some of the network computes are truly diskless, others may include a flash card or other comparable device that provides sufficient permanent storage to contain all code necessary to fully boot the computer. Still other devices on the network may include their own hard disks. Of the computers on a network that lack any significant local permanent storage, some may be configured to boot over the network via a protocol such as NFS, in which the boot server appears as a file device, other machines may be designed to boot via a simpler protocol such as the Trivial File Transfer Protocol (TFTP).
The TFTP is an internet protocol that allows users to transfer files to and from a remote machine, which may be specified on the command line. More detailed information regarding TFTP is available in K. Sollins, The TFTP Protocol (Revision 2), Internet RFC #1350 (1992), which is available from the RFC Editor at www.rfc-editor.com and is incorporated by reference herein. Unlike most devices that are used as boot devices, a TFTP compliant server supports only a limited set of commands. More specifically, TFTP supports read and write functions, but only for reading and writing consecutive blocks of data always starting from the beginning of the file. Code that is written for a boot device that appears as a file device (i.e., a device that supports open, close, read, write, and seek functions) is not functional on a TFTP network.
Network flexibility and reliability increases if each network computer is enabled to boot from a variety of boot devices. If a particular boot device is unavailable, a network computer can boot from an alternative device. Thus, it is desirable for a network computer to be able to boot from multiple boot devices. It is further desirable if complexity in the boot code is minimized. Accordingly, it is desirable to implement boot code for use in a computer network having multiple boot devices, where the boot device type is transparent to the boot code.
The problem identified is addressed by a method and software for booting a network computer with universal boot code that supports a variety of boot devices regardless of the specific functions supported by each boot device. Initially, the type of a boot device is determined from among a set of possible boot devices. A command in a high level boot code segment of the boot code software is then translated by a software interface of the boot code to a command executable by the boot device based upon the determined device type. The converted command is then executed on the boot device to transfer data between the network computer and the boot device. The boot code is preferably compatible with a variety of boot devices including a hard disk boot device, an NFS server boot device, as well as a TFTP server boot device. In an embodiment in which the boot device is a TFTP boot device, a READ command from the high level boot code is translated to a TFTP read request. The data transferred by the TFTP read request may be stored in a file cache on the network computer. During a subsequent high level boot code READ command, the software interface may determine if the requested data is cached in the file cache and, if so, it may retrieve the data from the file cache. If the high level boot command is a SEEK command, and the boot device is a TFTP device, the converted command may include a TFTP read request. The software interface may determine the relative location of a file location indicated by the SEEK command and a current location of a file pointer and abort the current TFTP transfer if the file location indicated by the SEEK precedes the current location of the file pointer. The interface may then resend a TFTP read request to advance the file pointer to the file location indicated by the SEEK command. In this manner, the software interface and device specific segments can emulate a file type device when the boot device is a TFTP device.